home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Mar 91 / MacApp.Tech$ 3⁄1⁄91 / 3110-Command Number Const-Feb91 < prev    next >
Encoding:
Text File  |  1991-04-01  |  1.9 KB  |  46 lines  |  [TEXT/GEOL]

  1. Item    8010429                         27-Feb-91        05:36PST
  2.  
  3. From:   POWERUP.ENG                     Power Up Software,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    Command Number Constants
  10.  
  11. Attn:   MacApp.Tech$
  12. SentBy: James Plamondon
  13. Subject:   Command Number Constants
  14. Gentlepersons,
  15.  
  16. It would be very handy if the command numbers used by MacApp were described by
  17. #define macros in MacAppTypes.r, so that the command numbers could be used by
  18. name in application Rez files.
  19.  
  20. I recently needed to create a STR# which was to be associated with the cOpen
  21. command number.  I assumed that the string 'cOpen' was #defined in the manner
  22. described above (in this case, to 20), and that I could say that the STR#'s
  23. resource ID number was cOpen (actually, 1000 + cOpen, to get it out of
  24. MacApp's reserved resource ID range).  Since this #define did not actually
  25. exist, I had to use the "magic number" 20 in my rez file (with a comment
  26. saying that it was intended to match the value assigned to cOpen in the
  27. definition of the type 'cmnu' in MacAppTypes.r).  My application relies on the
  28. relationship between the command number and the string list resource's ID.
  29. Should the command number assigned to cOpen change in the future, imagine the
  30. fun I will have tracking down the inconsistency.  (I could stop relying on the
  31. value of the command number, but only at considerable cost.)
  32.  
  33. Since we developer types have no control over the integer values assigned to
  34. these commands, and yet often need to refer to them in resources just as we do
  35. (and can) in source code, wouldn't it be nice to make them available to us in
  36. the described manner?  Then you could change the values all you wanted,
  37. without breaking my code (one of your highest compatibility goals, I'm sure.)
  38.  :-)
  39.  
  40. Hoping to squeeze just one last feature into MacApp 3.0, I remain
  41.  
  42. Yours,
  43.  
  44. James Plamondon
  45.  
  46.